1. Field of the Invention
The present invention generally relates to Presence Services, and more particularly to a system and method for controlling an operation of a Presence Source through external objects including a Presence Server.
2. Description of the Related Art
Conventionally, a Presence Service is a service that appropriately provides a set of objects with, for example, information about an ability and willingness of communication and a current status of a user or group corresponding to a target of interest, through a set of devices. The objects can detect the current status of the interest target based on received status information thereof, and can attempt contact with the interest target by selecting the best communication scheme.
FIG. 1 shows a Presence Service according to the prior art. A target of interest in the Presence Service is referred to as a Presentity. Information about the Presentity, i.e., Presence Information (PI), is published to a Presence Server 102 through Presence Sources 104. The Presence Server 102 composes the PI, generates the composed PI of the Presentity, and selectively sends notification of authorized PI to a subscribed Watcher 100 having an interest to the Presentity.
A signal flow between entities of Presence Service according to the prior art will be described with reference to FIG. 2A publication mechanism defined in Request for Comments (RFC) 3856 (“A Presence Event Package for the Session Initiation Protocol (SIP)”, by J. Rosenberg, August 2004), is applied between the Presence Sources 104 and the Presence Server 102. The Presence Source 104 or Event Publication Agents (EPA) transfers the PI about the Presentity to the Presence Server 102 or an Event State Compositor (ESC) using a Session Initiation Protocol (SIP) PUBLISH message in steps 204 and 205, steps 208 and 209, and steps 210 and 211. The Presence Server 102 for performing a composition function for the PI is referred to as the ESC. Further, the Presence Source 104 for performing a function for providing the PI is referred to as the EPA.
On the other hand, a Presence Event Package defined in RFC 3856 is applied between the Watcher 100 and the Presence Server 102. The Watcher 100 requests the PI for the Presentity using an SIP SUBSCRIBE message for a Presence Event in steps 200 to 203.
The Presence Server 102 or a Presence Agent (PA) transfers the PI received from the Presence Source 104 or a Presence User Agent (PUA) to the Watcher 100 using a SIP NOTIFY message in steps 204, 208, and 210.
An example of formats of messages used for the signal flow of FIG. 2 is illustrated in FIGS. 3A to 3D. Messages capable of being sent in steps 200 to 213 correspond to (a) to (n) of FIGS. 3A to 3D, respectively.
The Presence Service as described above can be implemented in Open Mobile al.liance (OMA) Presence SIMPLE V1.0. The architecture of OMA Presence SIMPLE V1.0 for supporting a Presence Service according to the prior art is shown in FIG. 4.
In the conventional Presence Service architecture, the Presence Source 104 maintains up-to-date PI about the Presentity viewed from a point-of-view thereof and transfers the PI to the Presence Server 102 through a SIP PUBLISH message whenever the PI is updated or changed. The Presence Server 102 composes the PI received from the Presence Sources 104 according to a predefined mechanism and maintains up-to-date composed PI. Further, the Presence Server 102 properly distributes the PI according to predefined policy using a SIP NOTIFY message in response to a SIP SUBSCRIBE request using a Presence Event Package of the Watcher 100. The SIP SUBSCRIBE request using the Presence Event Package of the Watcher 100 is a request for receiving the PI whenever the PI is updated.
FIG. 5 shows an operation of the Presence Source 104 according to the prior art.
When the Presence Source 104 is enabled in step 500, the Presence Source 104 determines whether PI about the Presentity is present in step 502. If the PI is present, the Presence Source 104 proceeds to step 504 to publish the PI to the Presence Server 102. Then, if the published PI is updated in step 506, the Presence Source 104 proceeds to step 508 and publishes the updated PI to the Presence Server 102.
Accordingly, the following behaviors are observed in the Presence Source 104.
The behavior of the Presence Source 104 is implicit. In the Presence Service shown in FIG. 1, it is assumed that the Presence Source 104 constantly performs a proper operation. Because there is not a method for enabling or disabling the operation of the Presence Source 104, the behavior of the Presence Source 104 is implicit.
The behavior of the Presence Source 104 is also independent. The Presence Source 104 independently determines whether update of the PI about the Presentity is present. Whenever the PI is updated, the Presence Source 104 determines and performs publication. That is, because the Presence Source 104 independently performs a determination or control without an external request or control, the behavior of the Presence Source 104 is independent.
As described in PDM (Draft-Ietf-Simple-Presence-Data-Model-06, “A Data Model for Presence”, by J. Rosenberg on Oct. 23, 2005), the above-described observations on the behaviors of the Presence Source 104 can be regarded negligible in the conventional architecture in relation to the existing purpose of the Presence Service for notification of the ability and willingness of communication using a set of devices of a predetermined user (i.e., Presentity). This is because, in the existing architecture, the PI is mostly composed of such discrete information as the communication ability and willingness, rather than continuous one. The Presence Sources for publication in the existing architecture are mostly configured with such persistent network entities as a user terminal or Home Subscriber Server (HSS). As such, the operation of the Presence Sources 104 is directly enabled/disabled and is independent.
However, as seen also in RPID (Draft-Ietf-Simple-Rpid-09, “RPID: Rich Presence Extensions to the Presence Information Data format”, H. Schulzrine et al., Sep. 24, 2005), the observed behaviors of the Presence Source 104 have the following problems when it is considered that the inherent purpose of the Presence Service for transferring information about the communication ability and willingness of a Presentity is being extended to a mechanism for providing various information about the Presentity, such as the current status thereof.
The implicit behavior of the Presence Source 104 disables a selective PI request and publication for the PI. For example, if the Presentity desires to know a snapshot of a used device at a particular time, the Presentity should transfer a PI publication request to an associated Presence Source so the snapshot of the associated PI can be published. In the Presence Service shown in FIG. 1, the Watcher can selectively send a request for a particular part of the PI using a filter method as described in Draft-Ietf-Simple-Event-Filter-Funct-05, “Functional Description of Event Notification Filtering”, H. Khartabil et al., Mar. 15, 2005. If the Presence Source responsible for publishing the associated information to the Presence Server 104 is not pre-activated, the Watcher cannot know the requested PI.
The independent behavior of the Presence Source 104 can cause an uncontrollable result. For example, when PI corresponding to a target of publication of a predetermined Presence Source is location information, the Presence Source 104 will publish the associated PI to the Presence Server 102 whenever the location information is updated. However, characteristics of quasi-continuous location information cause too frequent PI update and publication to give burden to an SIP based network and require high processing capability of the Presence Source 104 and the Presence Server 102. In RFC 3903 (“Session Initiation Protocol (SIP) Extension for Event State Publication”, A. Niemi et al., October 2004), a mechanism is proposed in which the Presence Server 102 can indirectly control a publication rate of the Presence Source 104 using a method for adjusting a publication expiration interval and including a Retry-After SIP header in a 503 Server Unavailable SIP response. However, the method for adjusting the publication expiration interval is used only for controlling the publication rate to refresh PI, but is not used for updating the PI. The method using the Retry-After SIP header is applied only to the next publication. Thus, the methods proposed in RFC 3903 are very limited for use and cannot be a fundamental resolution.